Picked this up to get it over the line. Four commits pushed on top of yours (nothing rewritten, main merged in rather than rebased). The PR description above is now stale — summary of what changed:

Updated for the released API

Workflow Streams and OpenAI Agents streaming both shipped in temporalio 1.30.0, so the contrib/pubsub install step is gone. Along with that:

• streaming_event_topic → streaming_topic, streaming_event_batch_interval → streaming_batch_interval.
• subscribe() without result_type now decodes payloads rather than handing back a raw Payload, so the assert isinstance(item.data, Payload) no longer holds. Subscribers pass result_type=RawValue and decode per topic, matching the merged workflow_streams/ samples.
• Dropped race_with_workflow (all of shared.py's 79 lines). Released subscribe() exits cleanly once the workflow reaches a terminal state, so the "subscriber blocked on its next poll forever" case it guarded against doesn't arise — break on the terminator, then await handle.result(). Confirmed by terminating a running workflow mid-subscribe: iterator exhausted cleanly, handle.result() raised WorkflowFailureError.
• Workflows now hold the run open briefly after publishing the terminator so a subscriber's last poll can drain the tail, same as workflow_streams/workflows/llm_workflow.py. The log lives in workflow memory, so it's gone the moment the run completes.

stream_items needed a rethink

The streaming activity publishes native OpenAI events, not the agents-SDK StreamEvent wrappers — so the agent_updated_stream_event / run_item_stream_event / tool_call_item events that subscriber matched on never appear on that topic, and it would have rendered nothing but === Run starting ===. Those higher-level events are built by the agents SDK inside the workflow.

So the workflow now publishes them itself, as a small serializable ItemEvent on its own items topic. It can't forward the SDK's own event types — RunItemStreamEvent carries the originating Agent, which holds tool callables. stream_events() resolves a turn at a time (one activity per model call), so the play-by-play still reaches the subscriber progressively rather than in one lump.

Same root cause in stream_text: it unwrapped a raw_response_event that isn't there. It now matches ResponseTextDeltaEvent directly.

Tests

tests/openai_agents/streaming_test.py — first tests under that directory, shaped after tests/strands_plugin/streaming_test.py. A scripted streaming model (_mock_model.py) means no OPENAI_API_KEY is needed; unlike the strands and ADK mocks it needs no monkeypatching, since OpenAIAgentsPlugin accepts a model_provider directly. test_stream_text asserts the deltas arrive unwrapped and reassemble into exactly the workflow's return value (this is the regression test for the wrapped-vs-native bug); test_stream_items asserts the four event kinds arrive in order. Both subscribe the way the runner scripts do and assert the terminator is seen.

Green on the local dev server and under --workflow-environment time-skipping, ~3s per run. poe lint clean.

Smaller things

Both workflow module docstrings sat below the imports, so they were dead string expressions rather than docstrings — moved to the top of the file. READMEs rewritten: branch-install notes dropped, the native-vs-wrapped event distinction documented, structure aligned with openai_agents/basic/README.md.

Still worth doing before merge

I verified end-to-end against a scripted model, not a live one. A run with a real OPENAI_API_KEY would confirm the batched-burst cadence the README describes, which is the one claim a fake model can't substantiate.